System and method for testing computer programs

ABSTRACT

A method for testing computer programs includes the steps of identifying at least one code subsection of a computer program to be tested, ascertaining one or more other code subsections required for executing the identified subsection, determining one or more input arguments required for executing the identified subsection and the other subsections, prompting a developer to provide at least one of the input arguments, and executing the identified subsection using the provided input arguments.

FIELD OF THE INVENTION

This invention is related to the field of computer program testing, andmore particularly, to systems and methods for testing computer programs.

BACKGROUND OF THE INVENTION

In general, computer programming environments require developers torigorously test and debug new computer programs prior to entering anytype of formal testing phase. Although tools are currently available forassisting developers in testing new programs, such tools typicallyrequire a substantial amount of a developer's time to configure thetools for testing even the smallest portion of a new program. Theadditional time expended to configure a testing tool not only canincrease the cost of developing a computer program, but can also reducethe amount of time developers are able to spend modifying and improvingthe computer program prior to its release.

SUMMARY OF THE INVENTION

In a first embodiment of the invention, a method for testing computerprograms can include the steps of identifying at least one codesubsection of a computer program to be tested, ascertaining one or moreother code subsections required for executing the identified subsection,determining one or more input arguments required for executing theidentified subsection and the other subsections, prompting a developerto provide at least one of the input arguments, and executing theidentified subsection using the provided input arguments.

In a second embodiment of the invention, a system for testing computerprograms can include a memory element operable to store one or more codesubsections of a computer program and at least one developer interfaceelement operable to allow a developer to identify at least one code ofthe code subsection of the computer program to be tested. The system canfurther include a processing element operable to ascertain one or moreother code subsections required for executing the identified subsection,to determine one or more input arguments required for executing theidentified subsection and the other subsections, to prompt a developerto provide at least one of the input arguments via the developerinterface, and to execute the identified subsection using the providedinput arguments.

In a third embodiment of the invention, a computer-readable storagemedium having stored thereon a computer program having a plurality ofcode sections for testing computer programs, can include code sectionsexecutable by a computer for causing the computer to perform the stepsof identifying at least one code subsection of a computer program to betested, ascertaining one or more other code subsections required forexecuting the identified subsection, determining one or more inputarguments required for executing the identified subsection and the othersubsections, prompting a developer to provide at least one of the inputarguments, and executing the identified subsection using the providedinput arguments.

This Summary is provided to comply with 37 C.F.R. §1.73, requiring asummary of the invention briefly indicating the nature and substance ofthe invention. It is submitted with the understanding that it will notbe used to interpret or limit the scope or meaning of the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a flowchart of exemplary steps of a method for testingcomputer programs according to an embodiment of the present invention.

FIG. 2 is a schematic view of an exemplary Graphical User Interface(GUI) for selecting a computer program to be tested according to anembodiment of the present invention.

FIG. 3 is a schematic view of an exemplary GUI for providing inputarguments for a computer program to be tested according to an embodimentof the present invention.

FIG. 4 is a schematic view of a computer system within which a set ofinstructions operate according to an embodiment of the invention.

DETAILED DESCRIPTION OF THE DRAWINGS

The present invention is described with reference to the attachedfigures, wherein like reference numerals are used throughout the figuresto designate similar or equivalent elements. The figures are not drawnto scale and they are provided merely to illustrate the instantinvention. Several aspects of the invention are described below withreference to example applications for illustration. It should beunderstood that numerous specific details, relationships, and methodsare set forth to provide a full understanding of the invention. Onehaving ordinary skill in the relevant art, however, will readilyrecognize that the invention can be practiced without one or more of thespecific details or with other methods. In other instances, well-knowndevices or operations are not shown in detail to avoid obscuring theinvention. The present invention is not limited by the illustratedordering of acts or events, as some acts can occur in different ordersand/or concurrently with other acts or events. Furthermore, not allillustrated acts or events are required to implement a methodology inaccordance with the present invention.

As previously described, various tools are available to developers fortesting and debugging computer programs during the development phase.One method is to use an “off the shelf” tool and adapt it for testing ofthe computer program being developed. However, because such tools aretypically designed for general use, they usually require that developersspend a significant amount of time modifying or configuring such toolsin order to test the computer program being developed. Another method isto develop a testing tool specifically designed to test the computerprogram being developed. However, such a method typically requiressignificant development time and resources. In some case, thedevelopment of such tools can require more time and resources than werenecessary for the development of the computer program it was designed totest.

In the embodiments of the invention, systems and methods for generatingtesting scenarios for specific computer programs using intelligentmethods and for performing testing of the computer program are provided.In particular, the embodiments of the present invention provide fortesting of computer programs by introspection of the computer program;that is, intelligently interrogating one or more identified codesections of the computer program, and dynamically generating developerinterfaces to prompt developers for any input information required forexecuting the identified code sections. Additionally, embodiments of thepresent invention can also identify other code sections (as well as anynecessary input information for these sections) required for testing theidentified code section. In some embodiments of the present invention,“stub” or stand-in replacement code sections can be provided where theneeded code sections are inaccessible or otherwise unavailable duringtesting.

Although various exemplary embodiments of the present invention may bedescribed in terms of specific programming languages or programmingenvironments, such description are intended only for the purpose ofillustration. One of ordinary skill in the art will readily recognizethat the invention is not limited in this regard and that inventiveaspects of the invention can be applied for use in the context of anytype of programming language or development environment.

FIG. 1 is a flowchart illustrating steps in an exemplary method 100 fortesting computer programs. First, as shown in Step 102, a developer ordevelopers can write a computer program to a mass storage device. In thevarious embodiments, the developer can write the computer program usinglocal or remote resources. Thus, the developer can write and store thecomputer program using only a local device or can access a remote devicevia a client terminal operating over a network. However, the inventionis not limited in this regard, and one of ordinary skill in the art canappreciate that in some embodiments a developer can write and store thecomputer programs using a combination of local and remote resources.Details on the operation of such remote and local devices are describedmore particularly below.

A computer program, as used herein, can be any collection ofinstructions that describes a task, or set of tasks, to be carried outby a computer. As such, a computer program, as described herein, canrefer to any collection of instructions, including a subsection of alarger computer program. Furthermore, these computer programs can bedescribed as an expression of a computational method written in acomputer language and can be categorized along functional lines. Thesefunctional categories include application software, operating systems,video games, and compilers, among others. The computer program can alsoembedded in hardware devices typically referred to as firmware.Additionally, computer programs, as used herein, can refer to either theformal expression of computational methods in a human-readable computerlanguage, often referred to as source code, or the machine-executableexpressions of computational methods commonly referred to asexecutables, object code, or simply as binaries—a reference to thebinary file format commonly used to store executable code.

Referring still to FIG. 1, after writing the computer program in Step102, the developer can begin the testing process. For example, as shownin Step 104, the developer can initialize a testing tool. Methods forselecting and initializing computer programs are well-known in the art.The testing tool, as described herein, can also be a computer program ora computer system executing instructions embodying the method 100. Thetesting tool can also be included as part of an operating system ordevelopment environment. However, the testing tool can also be aseparate computer program, accessed locally or remotely, depending onthe configuration being used by the developer. Therefore, the testingtool design and implementation can be affected by the complexity of thetesting that needs to be done, the experience of the developer ordevelopers, and the computing resources available. A testing tool for arelatively simple computer program can be a single, monolithic, separatecomputer program. However, if the computer program or the computerlanguage being used is large and complex, and if high quality output isrequired, the testing tool design may require that tasks be split into anumber of relatively independent phases or passes. Therefore, as one ofordinary skill in the art will recognize, the testing tool can bedeployed and operated using either local resources, remote resources, orany combination thereof.

Once the testing tool is initialized in Step 104, the developer can thenidentify code subsections of the computer program to be tested in Step106. Such code subsections can be identified by providing their locationin memory. Additionally, the code subsections can also be named by thedeveloper and the name can be used by the tool for identificationpurposes. In some embodiments, a combination of names and locations canbe used to identify specific subsections within a computer program. Ineither case, the code sections can be identified by enteringidentification or location information via a developer interface. In oneembodiment, illustrated in FIG. 2, a graphical developer interface (GUI)200 for Java classes can be provided that includes a developer inputsection 202 for entering a location and class name of the Java class tobe tested. However, the present invention is not limited to using theconfiguration of GUI 200, and other arrangements and methods, such asusing “wizards,” an alternate GUI configuration, or command lineinterface, are equally applicable to the present invention. The GUI isalso not limited to selection of Java classes and can also be configuredto select any type or combination of program fragments. By example andnot by way of limitation, for a given system, the GUI can be configuredto allow the developer to select between existing APIs (java/class),WSDLs, IDLs. XMLs, VXMLs, or any combination thereof.

As previously described, a computer program to be tested can compriseany set or subset of computer instructions. Therefore, a developer canchoose to test only one or more subsections of the computer program.Therefore, the developer is able to limit testing to only those featuresthe developer is currently developing or modifying. For example, a Javaclass may be used to define the operation of a GUI in a larger program.Therefore, rather than testing the entire computer program to simplytest the operation of the GUI Java class, the developer can choose onlyto test the GUI Java class, without requiring testing of other Javaclasses or using significant resources of the complete system. Such aconfiguration is advantageous in computer programs operating in largecomplex systems, as the portion being developed can be tested withouthaving to disrupt use of the complete system. However, the invention isnot limited in this regard, and one of ordinary skill in the art canappreciate that the developer can also identify multiple code sectionsor even an entire computer program for testing.

Referring back to FIG. 1, after the code sections to be tested areidentified in Step 106, the tool, in Step 108 can begin to analyze theidentified code sections. First, in Step 108, the tool can determineother code subsections that may be necessary for testing the identifiedcode subsection. That is, identified code subsections may be relying onother code subsections for functionality or input variables. The othercode subsections can be a part of the same computer program as theidentified code subsections. However, in some embodiments the other codesubsection can be parts of separate computer programs. For example, aJava class can make several calls to various public or private methods.Therefore, although the code subsections defining the operation of themethods are not included in the Java class, the tool can also retrievethe code subsections of the methods or at least determine where the codesections are located.

Once the tool has determined all of the code subsections that are neededfor testing the identified code subsection in Step 108, the tool, inStep 110, can then determine what type of input information is neededfrom the developer so as to properly test the identified subsections.That is, the tool can determine the input arguments needed for executionof the identified subsections, as well as any input arguments requiredby any other identified subsections. The input arguments can be valuesor locations of values that would normally be passed to a computerprogram. Such values can include any type of data or any portion of adata structure containing data to be used by the code subsections. Forexample, a Java class may be implemented to manipulate a set of data.Also, any methods being called by the Java class being tested canrequire input arguments that may be passed to the Java class, but thatmay not be used by the class until a method is called. Therefore, theinput arguments can include the location or values for the data to bemanipulated by the class or by any of the methods within the class.

After the tool determines the required input arguments in Step 110, thetool can generate an interface for the developer to provide the inputarguments in Step 112. The tool, via the interface, can then query thedeveloper in Step 114 so as to provide the various input argumentsrequired for successful execution of the identified code sections. Forexample, as shown in FIG. 3, a GUI 300 can be provided to allow adeveloper to input the various input parameters. In FIG. 3, the GUI 300include a method drop down box 302 configured to allow the developer toselect a method in the Java class being tested and additional inputfields 304 for entering the necessary input. However, the presentinvention is not limited to using a GUI, and other methods, such asusing a command line interface, are equally applicable to the presentinvention.

In some embodiments, it can be necessary to test the code sections undermultiple testing scenarios in order to rigorously test the codesections. Therefore, in some embodiments of the present invention, thetool can provide functionality to allow the developer to providemultiple sets of the input arguments and to associate there sets ofinput arguments with one or more scenarios. Accordingly, after thedeveloper specifies a set of input arguments, the tool can query thedeveloper, in Step 116, as to whether another scenario should bespecified. If other scenarios are to be specified, Steps 112-116 can berepeated until the developer provides input arguments for all thescenarios to be specified. Various methods for specifying and storingmultiple input arguments are well-known in the art. Once the developerindicates that no other scenarios are needed in Step 116, the tool, inStep 118, can store the multiple scenarios, including the associatedinput arguments in a test batch file. Various methods for specifying andstoring batch and/or data files are well-known in the art.

Typically, a computer program can male calls to one or more othercomputer programs. However, during development of a computer program,some portions of the computer program may be incomplete or unavailableto the developer, even though they are necessary for execution of theidentified code subsections. For example, a tool can have an interfaceto a remote server and not the underlying code to execute the remotecall on a remote server providing some type of function duringdevelopment.

Therefore, in embodiments of the present invention, the tool cangenerate substitute code or “stubs” that can stand in place of themissing code sections. For example, the tool, in Step 120, can determineif one of the other code sections required is currently unavailable orotherwise inaccessible to the testing tool. If such code sections areinaccessible, the tool can generate the necessary stubs in Step 122 sothat values can be passed between the identified code and the stubs toallow proper testing of the identified code sections. For instance, thestub can be configured to simulate the expected behavior of unavailableresources, such as a remote server performing one or more processes orprocedures. In some cases, the stub information can also be incorporatedinto the test batch file contents. Although the creation of stubsillustratively precedes execution of the identified code sections, oneof ordinary skill in the art can appreciate that stubs can also becreated dynamically during execution of the identified code sections orcan be created as the tool analyzes the code sections in Step 108.

Once all input arguments are provided, the tool, in Step 124, can loadinto active memory the input arguments necessary for executing theidentified code sections (and any other code sections). Subsequently,the identified code sections can be executed in Step 126. Upon executionof the identified code sections in Step 126, the tool can determine, inStep 128, if other scenarios have been specified by the developer andrepeat Steps 124-128 until all scenarios have been used to execute theidentified code sections. The output for each scenario can be presentedto the developer for evaluation in Step 130. For example, as shown inFIG. 3, an output region 306 of the GUI 300 can be used to display anoutput of identified code section. However, the present invention is notlimited in this regard and other known methods of presenting or storingoutput information for use by developers are equally applicable to thepresent invention.

Referring back to FIG. 1, if evaluation of the output by the developerindicates that the identified code sections do not need to be modified(that is, they are operating properly) in Step 132, then testing isended in Step 134. However, if the output is not correct in view of thedeveloper, the developer can modify the identified subsections in Step136 and resubmit the subsections for testing.

Although the testing can proceed by repeating Steps 102-134, in someembodiments, the identified subsections need not be reanalyzed todetermine the necessary input arguments, especially if the changes havenot resulted in any changes in necessary input arguments. Instead, thetest batch file created in step 118 can be used to skip analysis steps106-122, and the testing of the identified subsections can proceeddirectly to step 124 for additional testing.

In some embodiments, whether the identified code sections are to bereanalyzed can be specified by the developer upon resubmission. In otherembodiments, the determination can be made by the tool itself. In suchembodiments, the tool can be configured to analyze the modified portionsof the identified code sections and determine if the necessary inputarguments are different from those stored in the test batch file. Ifchanges are found, the developer can be prompted to provide at least thenew input arguments. In some cases, the tool can be configured torequire the developer to provide all input arguments anew. However, ifno changes in input arguments are found, the tool can then beginretesting the identified code sections in Step 124. Such a configurationallows the testing to be completed even more quickly and is advantageousin cases where the modifications to the identified code sections areminor.

However, even if changes in the identified subsections are minor,changes in the input arguments can still be necessary. For example, thedeveloper may wish to consider additional scenarios or may need to testspecific types of input arguments. Therefore, in some embodiments of thepresent invention, the tool can provide for modification of the testbatch file. In some cases, the developer can select to make the changesmanually. In other cases, if the test tool can query the developer inStep 138 if the developer wishes to make changes to the test batch filein response to any modifications in the identified subsections. In othercases, the developer can change the order of execution in the test batchfile.

Accordingly, if changes are needed, the developer, in Step 140, canmodify the scenarios or input arguments in the test batch file, andtesting can begin again in Step 124. However, the tool can also beconfigured to allow modification of the test batch file even if nochanges were made to the identified code subsections. For example, adeveloper may wish to consider an additional scenario or additionalranges of input arguments. In such embodiments, the tool can beconfigured to provide a prompt to a developer as to whether additionaltesting using a modified test batch file is desired. Accordingly,whether modifications to the identified subsections or the test batchfile are made, Steps 124-140 can be repeated as necessary until thedeveloper is satisfied with the output of the identified subsections.

Other modifications to the invention as described above are within thescope of the claimed invention. For example, the test batch file notonly can test scenarios separately, but also can be used to test aspecific sequence of scenarios. Thus any subsequent modifications of thescenarios can also include reordering the execution order of the variousscenarios being tested. In another example, the stubs need not begenerated for each identified code section. Instead, the developer canbe provided the option of specifying the locations of already generatedstubs, simulators, or alternate remote systems providing the necessaryfunctionality. For example, such information can be provided whileproviding input arguments. Alternatively, during selection of the codesections to be tested, the developer can also be provided with theopportunity to identify or to instruct the tool to generate any neededstubs, as shown by the selection boxes 204 in exemplary GUI 200. In yetanother embodiment, the test batch file can be stored for later use.Such a configuration allows for testing of the identified code sectionsat a later time, permitting the developer to retest the identified codesection if modifications are made at a later date or if it is believedthat changes in other code sections have affected the identified codesections.

FIG. 4 is a schematic diagram of a computer system 400 for executing aset of instructions that, when executed, can cause the computer systemto perform one or more of the methodologies and procedures describedabove. In some embodiments, the computer system 400 operates as astandalone device. In other embodiments, the computer system 400 can beconnected (for example, using a network) to other computing devices. Ina networked deployment, the computer system 400 can operate in thecapacity of a server or a client developer machine in server-clientdeveloper network environment, or as a peer machine in a peer-to-peer(or distributed) network environment.

The machine can comprise various types of computing systems and devices,including a server computer, a client developer computer, a personalcomputer (PC), a tablet PC, a laptop computer, a desktop computer, acontrol system, a network router, switch or bridge, or any other devicecapable of executing a set of instructions (sequential or otherwise)that specify actions to be taken by that device. It is to be understoodthat a device of the present disclosure also includes any electronicdevice that provides voice, video or data communication. Further, whilea single computer is illustrated, the phrase “computer system” shall beunderstood to include any collection of computing devices thatindividually or jointly execute a set (or multiple sets) of instructionsto perform any one or more of the methodologies discussed herein.

The computer system 400 can include a processor 402 (such as a centralprocessing unit (CPU), a graphics processing unit (GPU, or both), a mainmemory 404 and a static memory 406, which communicate with each othervia a bus 408. The computer system 400 can further include a displayunit 410 such as a video display (e.g., a liquid crystal display orLCD), a flat panel, a solid state display, or a cathode ray tube (CRT)).The computer system 400 can include an input device 412 (e.g., akeyboard), a cursor control device 414 (e.g., a mouse), a disk driveunit 416, a signal generation device 418 (e.g., a speaker or remotecontrol) and a network interface device 420.

The disk drive unit 416 can include a computer-readable storage medium422 on which is stored one or more sets of instructions 424 (forexample, software code) configured to implement one or more of themethodologies, procedures, or functions described herein, includingthose methods illustrated above. The instructions 424 can also reside,completely or at least partially, within the main memory 404, the staticmemory 406, and/or within the processor 402 during execution thereof bythe computer system 400. The main memory 404 and the processor 402 alsocan constitute machine-readable media.

Dedicated hardware implementations including, but not limited to,application-specific integrated circuits, programmable logic arrays, andother hardware devices can likewise be constructed to implement themethods described herein. Applications that can include the apparatusand systems of various embodiments broadly include a variety ofelectronic and computer systems. Some embodiments implement functions intwo or more specific interconnected hardware modules or devices withrelated control and data signals communicated between and through themodules, or as portions of an application-specific integrated circuit.Thus, the exemplary system is applicable to software, firmware, andhardware implementations.

In accordance with various embodiments of the present disclosure, themethods described herein can be stored as software programs in acomputer-readable storage medium and can be configured for running on acomputer processor. Furthermore, software implementations can include,but are not limited to, distributed processing, component/objectdistributed processing, parallel processing, virtual machine processing,which can also be constructed to implement the methods described herein.

The present disclosure contemplates a computer-readable storage mediumcontaining instructions 424 or that receives and executes instructions424 from a propagated signal so that a device connected to a networkenvironment 426 can send or receive voice and/or video data, and thatcan communicate over the network 426 using the instructions 424. Theinstructions 424 can further be transmitted or received over a network426 via the network interface device 420.

While the computer-readable storage medium 422 is shown in an exemplaryembodiment to be a single storage medium, the term “computer-readablestorage medium” should be taken to include a single medium or multiplemedia (for example, a centralized or distributed database, and/orassociated caches and servers) that store the one or more sets ofinstructions. The term “computer-readable storage medium” shall also betaken to include any medium that is capable of storing, encoding orcarrying a set of instructions for execution by the machine and thatcause the machine to perform any one or more of the methodologies of thepresent disclosure.

The term “computer-readable medium” shall accordingly be taken toinclude, but not be limited to, solid-state memories such as a memorycard or other package that houses one or more read-only (non-volatile)memories, random access memories, or other re-writable (volatile)memories; magneto-optical or optical medium such as a disk or tape; aswell as carrier wave signals such as a signal embodying computerinstructions in a transmission medium; and/or a digital file attachmentto e-mail or other self-contained information archive or set of archivesconsidered to be a distribution medium equivalent to a tangible storagemedium. Accordingly, the disclosure is considered to include any one ormore of a computer-readable medium or a distribution medium, as listedherein and to include recognized equivalents and successor media, inwhich the software implementations herein are stored.

Although the present specification describes components and functionsimplemented in the embodiments with reference to particular standardsand protocols, the disclosure is not limited to such standards andprotocols. Each of the standards for Internet and other packet switchednetwork transmission (e.g., TCP/IP, UDP/IP, HTML, and HTTP) representexamples of the state of the art. Such standards are periodicallysuperseded by faster or more efficient equivalents having essentiallythe same functions. Accordingly, replacement standards and protocolshaving the same functions are considered equivalents.

The illustrations of embodiments described herein are intended toprovide a general understanding of the structure of various embodiments,and they are not intended to serve as a complete description of all theelements and features of apparatus and systems that might make use ofthe structures described herein. Many other embodiments will be apparentto those of skill in the art upon reviewing the above description. Otherembodiments can be utilized and derived therefrom, such that structuraland logical substitutions and changes can be made without departing fromthe scope of this disclosure. Figures are also merely representationaland can not be drawn to scale. Certain proportions thereof may beexaggerated, while others may be minimized. Accordingly, thespecification and drawings are to be regarded in an illustrative ratherthan a restrictive sense.

Such embodiments of the inventive subject matter can be referred toherein, individually and/or collectively, by the term “invention” merelyfor convenience and without intending to voluntarily limit the scope ofthis application to any single invention or inventive concept if morethan one is in fact disclosed. Thus, although specific embodiments havebeen illustrated and described herein, it should be appreciated that anyarrangement calculated to achieve the same purpose can be substitutedfor the specific embodiments shown. This disclosure is intended to coverany and all adaptations or variations of various embodiments.Combinations of the above embodiments, and other embodiments notspecifically described herein, will be apparent to those of skill in theart upon reviewing the above description.

The Abstract of the Disclosure is provided to comply with 37 C.F.R.§1.72(b), which requires an abstract that will allow the reader toquickly ascertain the nature of the technical disclosure. It issubmitted with the understanding that it will not be used to interpretor limit the scope or meaning of the claims. In addition, in theforegoing Detailed Description, it can be seen that various features aregrouped together in a single embodiment for the purpose of streamliningthe disclosure. This method of disclosure is not to be interpreted asreflecting an intention that the claimed embodiments require morefeatures than are expressly recited in each claim. Rather, as thefollowing claims reflect, inventive subject matter lies in less than allfeatures of a single disclosed embodiment. Thus the following claims arehereby incorporated into the Detailed Description, with each claimstanding on its own as a separately claimed subject matter.

What is claimed is:
 1. A method for testing computer programs, themethod comprising: identifying at least one code subsection of acomputer program to be tested to yield an identified subsection;generating, via a processor, a test batch file for testing theidentified subsection, the generating comprising: ascertaining one ormore other code subsections required for executing a current version ofthe identified subsection; determining one or more input argumentsrequired for executing the identified subsection and the othersubsections to yield required arguments for the test batch file;retrieving previous input arguments available for a previous version ofthe identified code subsection and the other subsections; analyzing theprevious input arguments with respect to the required arguments toidentify which of the required arguments cannot be provided by theprevious input arguments due to no corresponding one of the previousinput arguments or a corresponding one of the previous input argumentsbeing at least one of invalid for the current version of the identifiedsubsection or invalid for the other subsections; for any of the requiredarguments that cannot be provided by the previous input arguments,prompting a developer to provide the one of the required arguments; andfor any of the required arguments that can be provided by the previousinput arguments, using the corresponding one of the previous inputarguments; and executing the current version of the identifiedsubsection using the test batch file.
 2. The method of claim 1, whereinthe provided input arguments are associated with one or more scenariosfor executing the identified subsection, and wherein the step ofexecuting further comprises executing the identified subsectionaccording to each of the scenarios.
 3. The method of claim 2, the testbatch file comprising a listing of the scenarios and the provided inputarguments associated with the scenarios.
 4. The method of claim 3,further comprising the steps of: retrieving the test batch file; andrepeating the step of executing using the scenarios in the test batchfile.
 5. The method of claim 3, further comprising the step of modifyingthe test batch file to adjust at least one among the provided inputarguments, an execution order for the scenarios, and a number of thescenarios.
 6. The method of claim 1, wherein the executing step furthercomprises: determining inaccessible ones of the other code subsections;generating stub code subsections for the inaccessible code subsections;and executing the stub code subsections in place of the inaccessiblecode subsections.
 7. The method of claim 1, wherein at least a portionof the executing step is performed using a simulated code sub-section.8. A system for testing computer programs comprising: a memory elementoperable to store one or more code subsections of a computer program, atleast one developer interface element operable to allow a developer toidentify at least one of the code subsections of the computer program tobe tested to yield an identified subsection; and a processing elementoperating without user intervention and configured to generate a testbatch file for testing the identified subsection and execute theidentified subsection using the test batch file, the generatingcomprising: ascertaining one or more other code subsections required forexecuting the identified subsection, determining one or more inputarguments required for executing the identified subsection and the othersubsections to yield required arguments for the test batch file,retrieving previous input arguments available for the identified codesubsection and the other subsections, analyzing the previous inputarguments with respect to the required arguments to identify which ofthe required arguments cannot be provided by the previous inputarguments due to no corresponding one of the previous input arguments ora corresponding one of the previous input arguments being at least oneof invalid for a current version of the identified subsection or invalidfor the other subsections, or unavailable, prompting a developer toprovide at least one of the input arguments via the developer interface,else using the previous input arguments to provide the input arguments,for any of the required arguments that cannot be provided by theprevious input arguments, prompting a developer to provide the one ofthe required arguments; and for any of the required arguments that canbe provided by the previous input arguments, using the corresponding oneof the previous input arguments.
 9. The system of claim 8, wherein theprovided input arguments are associated with one or more scenarios forexecuting the identified subsection, and wherein the processing elementis further configured to execute the identified subsection using theinput arguments associated with each of the scenarios.
 10. The system ofclaim 9, the test batch file comprising a listing of the scenarios andthe provided input arguments associated with the scenarios.
 11. Thesystem of claim 10, wherein the processing element is further configuredto: retrieve the test batch file; and repeat the step of executing. 12.The system of claim 11, wherein the interface element is furtherconfigured to allow a developer to alter the test batch file to adjustat least one among the provided input arguments, an execution order forthe scenarios, and a number of the scenarios.
 13. The system of claim 8,wherein the processing element is further configured to: determineinaccessible ones of the other code subsections; generate stub codesubsections for the inaccessible code subsections; and execute theidentified subsection using the stub code subsections in place of theinaccessible code subsections.
 14. A non-transitory computer-readablestorage medium having stored thereon, a computer program having aplurality of code sections for testing computer programs, the codesections executable by a computer for causing the computer to performthe steps of: identifying at least one code subsection of a computerprogram to be tested; generating, via a processor, a test batch file fortesting the identified subsection, the generating comprising:ascertaining one or more other code subsections required for executing acurrent version of the identified subsection; determining one or moreinput arguments required for executing the identified subsection and theother subsections to yield required arguments for the test batch file;retrieving previous input arguments available for a previous version ofthe identified code subsection and the other subsections; analyzing theprevious input arguments with respect to the required arguments toidentify which of the required arguments cannot be provided by theprevious input arguments due to no corresponding one of the previousinput arguments or a corresponding one of the previous input argumentsbeing at least one of invalid for the current version of the identifiedsubsection or invalid for the other subsections; for any of the requiredarguments that cannot be provided by the previous input arguments,prompting a developer to provide the one of the required arguments; andfor any of the required arguments that can be provided by the previousinput arguments, using the corresponding one of the previous inputarguments; and executing the current version of the identifiedsubsection using the test batch file.
 15. The non-transitorycomputer-readable storage medium of claim 14, further comprising codesections for associating the provided input arguments with one or morescenarios for executing the identified subsection according to developerinput, and wherein the code sections for the executing step furthercomprise code sections for executing the identified subsection accordingto each of the scenarios.
 16. The non-transitory computer-readablestorage medium of claim 15, the test batch file comprising a listing ofthe scenarios and the provided input arguments associated with thescenarios.
 17. The non-transitory computer-readable storage medium ofclaim 16, further comprising code sections for: retrieving the testbatch file; and repeating the step of executing using the scenarios inthe test batch file.
 18. The non-transitory computer-readable storagemedium of claim 16, further comprising code sections for modifying thetest batch file, the modifying comprising altering the test batch fileto adjust at least one among the provided input arguments, an executionorder for the scenarios, and a number of the scenarios.
 19. Thenon-transitory computer-readable storage medium of claim 14, wherein theexecuting step further code sections for: determining inaccessible onesof the other code subsections; generating stub code subsections for theinaccessible code subsections; and executing the stub code subsectionsin place of the inaccessible code subsections.
 20. The non-transitorycomputer-readable storage medium of claim 14, wherein the code sectionfor the executing step further comprise code sections for performing atleast a portion of the executing step in a simulated operatingenvironment.